Some embodiments of the present disclosure are directed to a recommendation system for evaluating alternative cloud architectures using automated workload instrumentation.
Trends in the landscape of computing platforms provides the motivation for such a recommendation system. In the context of a cloud-based platform, often a company subscribing for access to cloud resources might not utilize the full potential of the cloud infrastructure. As an example, some legacy systems administer “pay per use” schemes where the client of the cloud-based platform pays only for the time they use the system. In this case, the server (e.g., a virtual server hosted on the cloud infrastructure) would either be hosting the client's application (e.g., as one or more ready processes) or the client would have to delete the application altogether. In some cases, there is no “suspension” mode where the client is not charged even though interaction with the application is quiescent or minimal. That is, if the customer wants to stop paying for the configured cloud resources, the only option is to suspend the client application, take a snapshot of the application from within the cloud server, store the snapshot, and then delete the process or processes of the client application for a later restoration. In most cases, such a suspend-snapshot-delete-restore is impractical.
As another example a company might initially deploy on a workstation-like (e.g., compute-intensive) configuration, and later discover that database-like operations dominate the computing resource usage. Commercially, this can result in a “pain point” for the client of the cloud resource, namely that the client ends up paying for unused (but configured and available) computing resources while the needed (but under-specified) services are lacking. Of course, the client wants to pay only for the needed (e.g., configured and utilized) resources, and not for unneeded (e.g., configured and under-utilized) resources.
Unfortunately, legacy systems for analyzing and configuring computing platforms are deficient in many regards, especially as regards evaluating alternative cloud architectures. For example, earlier attempts were motivated by the high cost of performing in-situ testing, and techniques developed to address this high cost relied on modeling or profiling of a computer system, and/or modeling or profiling a workload rather than employing actual measurement techniques. The models in these legacy systems were often oversimplified, were not tied to any specific hardware implementation, and generally failed to account for the interaction of the many components in a computer system. In the limited cases when performance modeling was used in these legacy systems, they relied on external performance measurement tools in order to calculate a profile of a computing system for use in making system performance predictions and estimations. Worse, the aforementioned legacy techniques failed to refine the models or profiles based on in-situ testing or comparisons. In absence of in-situ measurements, the legacy models or profiles failed to provide good visibility into resource utilization, application performance, and operational health of the platform, and legacy systems failed to offer “comparables” (e.g., comparisons with other similar cloud applications, comparisons against alternative configurations, etc.). Moreover, the aforementioned technologies do not recommend alternative cloud configurations based on automated test measurements. Therefore, there is a need for an improved approach.